SCS Sensor Configuration Editor

COM Interfaces

COM (Communication port) is the original, yet still common, name of the serial port interface on IBM PC-compatible computers. 

Most PC-compatible computers in the 1980s and 1990s had one or two COM ports. As of 2007, most computers shipped with one or no physical COM ports. As of 2014, consumer-grade PC-compatible computers don't include any COM ports, though some of them do still include a COM header on the motherboard.

 

After the RS-232 COM port was removed from most consumer-grade computers in the 2000s, an external USB-to-UART serial adapter cable was used to compensate for the loss. A major supplier of these chips is FTDI.

 

The COM ports are interfaced by an integrated circuit such as 16550 UART. This IC has seven internal 8-bit registers which hold information and configuration data about which data is to be sent or was received, the baud rate, interrupt configuration and more. In the case of COM1, these registers can be accessed by writing to or reading from the I/O addresses 0x3F8 to 0x3FF.

If the CPU, for example, wants to send information out on COM1, it writes to I/O port 0x3F8, as this I/O port is "connected" to the UART IC register which holds the information that is to be sent out.

The COM ports in PC-compatible are typically defined as:

• COM1: I/O port 0x3F8, IRQ 4
• COM2: I/O port 0x2F8, IRQ 3
• COM3: I/O port 0x3E8, IRQ 4
• COM4: I/O port 0x2E8, IRQ 3

 

Given the lack of COM support in modern computers and the need for a large number of serial inputs required by SCS most ships utilize an multi-port adapter to provide a series of external COM interfaces.  Most NOAA ships use COMTROL or DIGI adapters to provide these inputs. 

 

The Basic tab consists of the following fields:

• Description
  • Provide an optional description of this item. 
• System Name
  • System generated name, read only format standard across all SCS systems.  
  • Useful for post-processing data on shore from multiple different sources/vessels.
  • Useful for rotating personnel as each ship will always comply with this format.
  • If you wish to have a more user friendly name you can edit the Display Name attribute below
• Display Name
  • User supplied name
  • Can be anything you wish though must be unique.
• Type
  • The Type of Sensor Interface being defined.  
  • This is set upon creation and cannot be changed after the fact.  You can copy the interface's Message Definitions and paste them into a new interface of a different type if needed.
• Enabled
  • A flag letting SCS know if this interface is actively providing data or if it should be ignored by client applications such as ACQ.
• Installed To
  • If the Physical Device is actually supplying data to SCS you can link those datasets to this specific device by Installing the device to the Sensor Interface.  When you swap a physical sensor out be sure to update this portion of SCS to reflect your changes!
• COM Port
  • The actual numeric port SCS should open to pull data from this interface.
• Baud Rate
  • The rate at which data should be expected to flow through this interface.

 

 

The Advanced tab consists of the following fields:

• Comment
  • A general comment pertaining to this item
• Keywords
  • Optional tags used to assist with text searches and metadata
• Installed To
  • Similar to the Installed property on the Basic tab, however this instance allows you to manage historic installations.
• Data Bits
  • The number of data bits in each character can be 5 (for Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for most kinds of data, as this size matches the size of a byte), or 9 (rarely used). 8 data bits are almost universally used in newer applications. 5 or 7 bits generally only make sense with older equipment such as teleprinters.
• Stop Bits
  • Stop bits sent at the end of every character allow the receiving signal hardware to detect the end of a character and to resynchronise with the character stream. Electronic devices usually use one stop bit. If slow electromechanical teleprinters are used, one-and-one half or two stop bits are required.
• Parity
  • A method of detecting errors in transmission. When parity is used with a serial port, an extra data bit is sent with each data character, arranged so that the number of 1 bits in each character, including the parity bit, is always odd or always even. If a byte is received with the wrong number of 1s, then it must have been corrupted. However, an even number of errors can pass the parity check.

    Electromechanical teleprinters were arranged to print a special character when received data contained a parity error, to allow detection of messages damaged by line noise. A single parity bit does not allow implementation of error correction on each character, and communication protocols working over serial data links will have higher-level mechanisms to ensure data validity and request retransmission of data that has been incorrectly received.

    The parity bit in each character can be set to one of the following:

    • None (N) means that no parity bit is sent at all.
    • Odd (O) means that parity bit is set so that the number of "logical ones" must be odd.
    • Even (E) means that parity bit is set so that the number of "logical ones" must be even.
    • Mark (M) parity means that the parity bit is always set to the mark signal condition (logical 1).
    • Space (S) parity always sends the parity bit in the space signal condition (logical 0).
  • Aside from uncommon applications that use the last bit (usually the 9th) for some form of addressing or special signaling, mark or space parity is uncommon, as it adds no error detection information. Odd parity is more useful than even parity since it ensures that at least one state transition occurs in each character, which makes it more reliable at detecting errors like those that could be caused by serial port speed mismatches. The most common parity setting, however, is "none", with error detection handled by a communication protocol.
• Flow Control

  • In many circumstances a transmitter might be able to send data faster than the receiver is able to process it. To cope with this, serial lines often incorporate a "handshaking" method, usually distinguished between hardware and software handshaking.

    Hardware handshaking is done with extra signals, often the RS-232 RTS/CTS or DTR/DSR signal circuits. Generally, the RTS and CTS are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. DTR and DSR are usually on all the time and, per the RS-232 standard and its successors, are used to signal from each end that the other equipment is actually present and powered-up. However, manufacturers have over the years built many devices that implemented non-standard variations on the standard, for example, printers that use DTR as flow control.

    Software handshaking is done for example with ASCII control characters XON/XOFF to control the flow of data. The XON and XOFF characters are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the data being sent. The circuit starts in the "sending allowed" state. When the receiver's buffers approach capacity, the receiver sends the XOFF character to tell the sender to stop sending data. Later, after the receiver has emptied its buffers, it sends an XON character to tell the sender to resume transmission. It is an example of in-band signaling, where control information is sent over the same channel as its data.

    The advantage of hardware handshaking is that it can be extremely fast; it doesn't impose any particular meaning such as ASCII on the transferred data; and it is stateless. Its disadvantage is that it requires more hardware and cabling, and these must be compatible at both ends.

    The advantage of software handshaking is that it can be done with absent or incompatible hardware handshaking circuits and cabling. The disadvantage, common to all in-band control signaling, is that it introduces complexities in ensuring that a) control messages get through even when data messages are blocked, and b) data can never be mistaken for control signals. The former is normally dealt with by the operating system or device driver; the latter normally by ensuring that control codes are "escaped" (such as in the Kermit protocol) or omitted by design (such as in ANSI terminal control).

    If no handshaking is employed, an overrun receiver might simply fail to receive data from the transmitter. Approaches for preventing this include reducing the speed of the connection so that the receiver can always keep up; increasing the size of buffers so it can keep up averaged over a longer time; using delays after time-consuming operations (e.g. in termcap) or employing a mechanism to resend data which has been corrupted (e.g. TCP).

 

The default setup for NMEA-0183 (not NMEA-0183HS) compliant sensors coming over serial COM ports is generally:

Baud Rate	4800
Data bits	8
Parity	None
Stop bits	1
Handshake	None

 

 

 - Much of above was taken from: https://en.wikipedia.org/wiki/COM_(hardware_interface) and https://en.wikipedia.org/wiki/Serial_port

 

 

SCSv5                                                                                                        Page 1 of 1